\chapter{Norme di comportamento}
Le \textit{norme di comportamento} sono atte a regolamentare tutta una serie di situazioni non necessariamente legate al codice o alla documentazione. Le comunicazioni tra membri del gruppo, l'utilizzo del \textit{server svn} e in generale l'utilizzo di altre risorse condivise, sono tutti aspetti regolamentati da questo capitolo.

\section{Applicazione delle norme}
Le modifiche al documento e le nuove norme introdotte nel documento devono sempre essere acquisite (lette e applicate) dal momento stesso in cui vengono rese note ai membri del gruppo. Questo significa che dal momento in cui viene resa nota a tutti i membri del gruppo una modifica al presente documento, ogni membro del gruppo è tenuto a consultare il diario delle modifiche del documento stesso e a prendere visione dei cambiamenti e delle nuove norme introdotte. Le norme e le modifiche introdotte vanno applicate immediatamente e sono considerate in vigore dal momento della notifica.

\section{Migrazione tra norme}
Quanto segue si applica a tutte le norme modificate e alle norme appena introdotte, per le quali siano necessari cambiamenti al codice o alla documentazione. Ossia in tutti quei casi in cui una norma appena introdotta entri in contrasto con una norma fino a quel momento in uso.
In questi casi verranno concordati all'intenro del gruppo dei tempi massimi per portare a termine la modifica di tutte le risorse interessate. Entro tale termine tutte le risorse interessate dovranno rispettare la nuova norma. Una volta definito un tempo massimo per la mirazione da una norma a un'altra, verrà creato un nuovo \textit{issue} di tipo \textit{Task Request} con priorità \textit{critica}. \`E importante infatti che la situazione di incosistenza in cui ci si trova venga risolta al più presto.

\section{Modifica a una norma}
Le modifiche alle norme vigenti, o l'introduzione di nuove norme deve essere discussa ed approvata da almeno la metà dei componenti del gruppo. Tale discussione deve avvenire con la creazione di una nuova \textit{issue} di tipo \textit{Task Request} nella quale verranno suggeriti i cambiamenti da apportare al documento. Va inviato un \textit{alert} segnalando l'indirizzo dell'issue in modo che ognuno sia reso partecipe della discussione e possa aggiungere il suo nome nel campo \textit{CC}. La stessa issue dovrà poi restare nello stato di \textit{Waiting} (attesa), finchè almeno metà dei membri del gruppo non si sarà espressa.\\
In alternativa è possibile fissare nel testo della issue un tempo massimo non inferiore ai sette giorni (una settimana), scaduto il quale lo sviluppatore incaricato provvederà ad aggiungere al documento le norme e le eventuali modifiche prese in considerazione. Al termine della stesura dovrà notificare l'aggiornamento del documento mediante \href{https://sites.google.com/site/xideproject/alerts-1}{alert}.

\section{Account Google}
A causa del forte numero di \textit{risorse Google} utilizzate (prese in considerazione nelle prossime sezioni), ogni membro del gruppo deve essere in possesso di un account Google, ossia ogni membro del gruppo deve essere raggiungibile mediante un indirizzo email di tipo \href{http://mail.google.com}{Gmail}.

\section{Google Sites}
Uno dei servizi utilizzati dal gruppo è Google Sites. In particolare esso viene utilizzato come intranet del gruppo, ed è accessibile ai soli membri del gruppo a questo indirizzo: \href{https://sites.google.com/site/xideproject/}{https://sites.google.com/site/xideproject/}. L'intranet viene utilizzato per gli \href{https://sites.google.com/site/xideproject/alerts-1}{alerts} (di cui parleremo nelle prossime sezioni), per ospitare online \href{https://sites.google.com/site/xideproject/pages/guide-e-tutorial}{guide e tutorial} necessari ai mebri del gruppo, per ospitare i \href{https://sites.google.com/site/xideproject/pages/verbali-riunioni}{verbali} delle riunioni del gruppo e in generale come supporto alla coordinazione del gruppo.

\section{Guide e Tutorial}
La sezione \href{https://sites.google.com/site/xideproject/pages/guide-e-tutorial}{Guide e Tutorial} del nostro \textit{intranet} raccoglie guide utili  ai membri del gruppo. Ogni guida o tutorial deve rispettare delle regole di stesura.
\begin{itemize}
\item Non vanno caricate immagini su Google Sites, perchè lo spazio a disposizione è ridotto e inoltre non esiste un manager per la gestione e la rimozione delle immagini inutilizzate. Le immagini vanno quindi linkate e ospitate su \href{http://picasaweb.google.com/}{Picasa} (di cui parleremo successivamente).
\item Vanno utilizzati gli header per i titoli di paragrafi e sezioni di ogni tutorial o guida. Sotto il menù \textit{Format} trovate diversi tipi di header. Gerarchizzate la guida secondo questi header.
\item Ogni guida e tutorial deve includere in testa subito sotto il titolo della \textit{pagina} una \textit{Table of Contents}, gadget di Google che riassume i titoli della pagina fornendo un indice alla stessa.
\item Ogni nuova sezione di una guida o di un tutorial deve cominciare con una linea orizzontale (\textit{Insert-\textgreater Horizontal Line}) seguita da tre righe vuote e dal titolo della sezione in formato \textit{H2}.
\item I sottoparegarafi di ogni sezione devono utilizzare in questo ordine gli altri header: \textit{H3} per i paragrafi, \textit{H4} per i sottoparagrafi. Ogni blocco di testo (sia esso paragrafo o sottoparagrafo) deve essere indentato di un livello rispetto al paragrafo o alla sezione che lo contiene.
\item Il titolo di ogni paragrafo o sottoparagrafo deve essere separato mediante una linea vuota dal testo sovrastante.
\item Ogni qual volta si ritenga necessario inserire un pezzo di codice, un listato o il contenuto di un file all'intenro di una guida o di un tutorial, questo va inserito dentro una \textit{text bo}x (Insert-\textgreater Text Box).
\item Non vanno realizzate guide eccessivamente complesse, utilizzate sempre dove possibile link a risorse esterne (come \textit{Wikipedia}).
\item Nel caso dobbiate linkare una pagina interna al sito, non dovete utilizzare il link diretto, ma lo strumento di ricerca pagine di Google Sites. In questo modo modificando la posizione di una pagina all'interno del sito il \textit{CMS} si arrangerà a riposizionare tutti i link che puntano a quella pagina.
\item Ogni qual volta il discorso sia troppo complesso, o la linearità del testo non permetta di spiegare bene un discorso, considerate l'utilizzo di immagini, diagrammi e schemi.
\item Realizzate diagrammi e schemi di qualità con colori differenti che aiutino la comprensione ed eventualmente la memorizzazione. Se non vi ritenete in grado di realizzare un diagramma di qualità elevata affidatene la realizzazione ad altri membri del gruppo.
\end{itemize}

\section{Verbali delle Riunioni}
La sezione \href{https://sites.google.com/site/xideproject/pages/verbali-riunioni}{Verbali Riunioni} del nostro \textit{intranet} raccoglie i resoconti delle riunioni del nostro gruppo. Ogni qual volta si ritiene necessario trovarsi di persona per discutere problemi e scelte importanti per il gruppo, verrà indetta una riunione. Indire una riunione significa creare un nuovo verbale (secondo le regole definite di seguito) e  all'interno dello stesso proporre una data e un luogo dove si terrà la riunione stessa. Vanno poi avvisati tutti gli utenti del gruppo mediante \textit{alerts} (di cui parleremo successivamente). Ogni utente è tenuto a notificare mediante commenti sulla pagina la sua disponibilità ed eventuali variazioni di orario o di luogo. Una volta definiti un orario e un luogo la riunione si terrà secondo quanto descritto nella sezione \textit{Riunioni di Gruppo}. Vediamo ora secondo quali norme deve essere costruita la pagina del verbale:
\begin{itemize}
\item Come titolo va scritto: \textit{Riunione} seguita dal numero della riunione (tale numero è l'intero successivo al numero della riunione precedente). Una volta definita la data questa verrà aggiunta al titolo inserita tra due parentesi tonde e scritta secondo quanto definito nella sezione \textit{Date} di questo stesso documento.
\item Va inserita una \textit{Table of Contents} in testa alla pagina, in modo da fornire un indice interattivo al verbale.
\item Vanno create tre sezioni intitolate rispettivamente: \textit{Obiettivi}, \textit{Resoconto} e \textit{Conlcusioni}, più altre eventuali sezioni.
\item Ogni sezione deve cominciare con una \textit{Horizontal Line} seguita da tre linee vuote e dal titolo evdenziato in formato \textit{H2}.
\item Ogni eventuale sottosezione deve utilizzare in ordine gli \textit{header} \textit{H3} e \textit{H4} indentandosi di un livello rispetto alla sezione contenente.
\item La sezione \textit{obiettivi} deve contenere in formato testo, ognuno su una riga separata i seguenti valori:
	\begin{itemize}
	\item \textit{Data:} affianco al quale va inserita la data prevista per l'evento (la quale verrà eventualmente modificata successivamente).
	\item \textit{Orario previsto}: affianco al quale va inserito un orario di inizio ed un eventuale orario di fine (i quali potranno essere successivamente modificati). \`E eventualmente possibile non definire un orario di fine nel caso si scriva come orario di fine la parola ``A oltranza''.
	\item \textit{Luogo:} affianco al quale andrà inserito un luogo (il quale potrà essere eventualmente modificato in seguito).
	\item \textit{Relatore:} affianco al quale verrà scritto nome e cognome di colui che dovrà coordinare la riunione (regolare gli interventi ed esporre gli obiettivi), Il relatore è tenuto a leggere e a comprendere gli obiettivi della riunione in quanto sarà lui ad esporli (non è invece tenuto a portare una copia stampata degli obiettivi alla riunione).
	\item \textit{Verbale affidato a:} affianco al quale va scritto nome e cognome di colui che dovrà occuparsi di prendere appunti durante la riunione e stendere il verbale finale all'interno dell'intranet. La persona a cui viene affidato il verbale va concordata tra i membri del gruppo tenendo conto del fatto che nessuno può essere escluso dal ruolo di redattore del verbale, valutando inoltre il carico di lavoro di ogni membro del gruppo e cercando di affidare l'incarico al membro del gruppo più disponibile. Il responsabile del verbale è tenuto a presentarsi alla riunione con una copia (digitale o cartacea, a seconda delle disponibilità) del verbale in questione e dovrà preoccuparsi di prendere nota di quanto detto ed espresso durante la riunione.
	\end{itemize}
La sezione \textit{obiettivi} deve inoltre contenere una sottosezione denominata \textit{Argomenti:} dove deve essere inserito l'elenco degli argomenti da trattare alla riunione.\\
Le modifiche agli argomenti (di un verbale) possono essere fatte solo entro 72 ore prima della data della riunione e non oltre (tre giorni prima).\\
Nell'elenco degli argomenti devono essere inseriti anche tutti gli obiettivi non conclusi o tralasciati dalla riunione precedente (è possibile trovare un elenco degli stessi sotto la sezione \textit{Conclusioni} del verbale della riunione precedente).\\
La sezione \textit{Argomenti} deve essere seguita dalla sottosezione \textit{Prerequisiti:} dove devono essere elencati tutti i prerequisiti necessari alla riunione, ossia l'elenco delle risorse (\textit{issue}, articoli, documenti) importanti per la buona riuscita della riunione.\\
Le modifiche ai prerequisiti (di un verbale) possono essere fatte solo entro 72 ore prima della data della riunione e non oltre (tre giorni prima), in modo che chiunque abbia tempo di visionare il materiale necessario alla riunione.
\item La sezione \textit{resoconto} deve contenere in formato testo ognuno su una riga separata i seguenti valori:
	\begin{itemize}
	\item \textit{Presenti:} dove devono essere scritti i nomi di tutti i presenti. \`E però possibile raggruppare i nomi in diverse categorie, come ad esempio ``Sviluppatori coinvolti nell'issue 3'' oppure ``Verificatori'' o solo se assodato ``Tutti''. Vanno inoltre scritte in questo campo tutte le partecipazioni parziali, ossia quei membri che hanno partecipato in modo parziale alla riunione.
	\item \textit{Orario Effettivo:} affianco al quale va scritto l'orario effettivo della riunione, in modo da valutare ritardi ed eventuali assenze parziali di alcuni membri del gruppo.
	\item \textit{Luogo Effettivo:} affianco al quale va scritto il luogo effettivo in cui si è tenuta la riunione.
	\end{itemize}
Il resoconto va poi completato con la formalizzazione degli appunti presi durante la riunione elencando (mediante l'utilizzo di un elenco puntato e di altre strutture ipertestuali) le scelte prese durante la riunione.
\item Nella sezione \textit{Conclusioni}, vanno scritti gli obiettivi concordati (in forma di riassunto, senza entrare nei dettagli) e gli obiettivi non conclusi o non esaminati (in forma di elenco puntato, tali obiettivi verranno inseriti come argomenti di discussione della riunione successiva).
\end{itemize}
Nel caso una persona non possa portare a termine la stesura di un verbale affidatagli, dovrà provvedere ad aprire un apposita \textit{issue} su \textit{Google code}.

\section{Picasa}
Ogni membro del gruppo che debba utilizzare immagini (inerenti l'attività di gruppo) sulle guide di Google Sites o su altri servizi online è tenuto a caricarle in un apposito album privato nel proprio account \href{http://picasaweb.google.com/}{Picasa}. In questo modo non si va ad occupare lo spazio degli altri servizi, e inoltre è possibile organizzare e cancellare le immagini non più utilizzate.

\section{Alerts}
La pagina \href{https://sites.google.com/site/xideproject/alerts-1}{Alerts} del nostro intranet contiene una lista ordinata di notifiche. Gli alert sono messaggi brevi che servono a informare tutti i membri del gruppo di avvenimenti importanti. Ogni alert (o notifica) è composto da due campi. Il primo campo è l'avviso in forma di testo semplice. il secondo campo è un link ipertestuale. Gli alert vanno utilizzati come principale fonte di notifica all'interno del gruppo (per segnalare aggiornamenti, proposte di riunione, nuove guide). Per fare in modo che ogni componente del gruppo riceva le notifiche degli alerts, è necessario che ogni componente vada nella pagina \textit{Alerts} e selezioni dal menù \textit{Altre azioni} la voce \textit{Richiedi notifica modifiche pagina}. In questo modo riceverà un email per ogni \textit{alert} creato o modificato.

\section{Account Gmail}
Non è obbligatorio ma è fortemente consigliata la creazione di due filtri sul proprio account \href{http://mail.google.com}{Gmail}. I due filtri dovranno essere creati con le seguenti descrizioni sintetiche:
\begin{small}
\begin{itemize}
\item \texttt{from:(xIDE Project \textless noreply@google.com\textgreater) subject:([xIDE Project])}
\item \texttt{from:(codesite-noreply@google.com) xideproject}
\end{itemize}
\end{small}
Atti a filtrare rispettivamente gli alert provenienti dall'intranet e le notifiche provenienti da \href{http://code.google.com/}{Google Code}. Entrambi i filtri devono avere come unica e sola azione quella di appliccare un etichetta ``xIDE'' ai messaggi filtrati. In questo modo è possibile individuare con un veloce colpo d'occhio le email provenienti dal progetto xIDE.

\section{Altre comunicazioni}
Non sono ammesse altre comunicazioni formali tra membri del gruppo. Nel caso quindi si renda necessario comunicare qualcosa di importante ai fini dello sviluppo a tutti i membri del gruppo, bisognerà utilizzare gli \textit{alert} e non, email, mailing list, chat, comunicazioni orali, analogiche o digitali di ogni sorta. La discussione di problemi va inoltre fatta mediante utilizzo di \textit{issue}, nei quali i diversi componenti esprimeranno i loro pareri, perplessità e soluzioni.\\
In altre parole è possibile discutere apertamente purchè le discussioni una volta concretizzate vengano riportate sotto forma di commenti negli \textit{issue}. Allo stesso modo è possibile comunicare via mail, chat e voce avvenimenti importati a patto di averli preventivamente segnalati mediante \textit{alert}. Questo serve a garantire che tutte le decisioni abbiano un riscontro documentato non volatile e che tutte le comunicazioni importanti siano affidate a un sistema sicuro in grado di raggiungere ogni sviluppatore.

\section{Riunioni di Gruppo}
Durante le riunioni di gruppo ci si trova in luoghi possibilmente non affollati e caotici. Il relatore scelto come indicato sopra nel verbale esporrà in ordine (uno alla volta) gli argomenti all'ordine del giorno. Coordinando gli interventi, richiamando all'ordine, e se possibile utilizzando una lavagna come strumento d'appoggio al proficuo svolgimento della riunione. L'addetto alla stesura del verbale dovrà prendere minuziosamente nota dei problemi sorti nella discussione, delle alternative proposte e delle decisioni finali.

\section{Google Code}
\href{http://code.google.com/}{Google Code} è un servizio di hosting per progetti open source. Il nostro gruppo lo utilizza principalemente per tre motivi. Prima di tutto per il \href{http://code.google.com/p/xideproject/source/checkout}{server svn}. In secondo luogo per il sistema di tracciamento di task e bug (\href{http://code.google.com/p/xideproject/issues/list}{Issue Tracking}) e infine come host per i download futuri del nostro software.
Ogni membro del gruppo deve essere a conoscenza di come viene utilizzato un svn (vedi \href{https://sites.google.com/site/xideproject/guide-e-tutorial/guida-svn}{Guida SVN}, \href{https://sites.google.com/site/xideproject/guide-e-tutorial/guida-a-rapidsvn}{Guida a RapidSVN}) e come utilizzare il sistema di issue (vedi \href{https://sites.google.com/site/xideproject/guide-e-tutorial/google-code-issue}{Google Code: Issue}).

\section{Svn Commit}
Ogni membro del gruppo è tenuto ad eseguire un checkout prima di ogni modifica e del successivo commit. \`E inoltre vietato intervenire su file a cui non si è stati assegnati (come proprietario o verificatore). \`E consigliato eseguire commit frequenti solo in casi particolari (quando ad esempio si sta lavorando in più persone sullo stesso file, o quando non si è sicuri delle prestazioni del proprio computer). Ogni commit va accompagnato con un commento obbligatorio, nel commento bisogna fornire informazioni in modo sintetico circa i file modificati e le modifiche apportato facendo riferimento all'issue correlato. \`E importante che nel commento sia scritto l'issue correlato (scrivendo issue seguito dal numero dell'issue stesso) perchè \textit{Google Code} trasforma gli issue in link ipertestuali all'issue stesso. In questo modo la revisione e l'issue non sono solo correlati ma anche linkati fra loro. Nel messaggio del commit va inoltre indicato l'eventuale incremento di versione dei documenti modificati.

\section{Creazione Issues}
Alla creazione di una nuova issue, bisogna scegliere tra diversi modelli di issue. In particolare se dovete segnalare un difetto del software utilizzate il \textit{Defect Report from Developer} (e non quello per gli utenti). Se dovete richiedere una verifica del codice utilizzate il \textit{Review Request}. Se dovete affidare un compito generico a qualcuno utilizzate \textit{Task Request}. Se dovete segnalare un errore nella documentazione o su altro materiale (che non sia codice) utilizzate \textit{Documentation Defect from Developer}. Definite una priorità adeguata e applicate all'issue le sole etichette utili a descriverlo meglio. Bisogna inoltre aggiungere nel campo CC il nominativo del verificatore, che si occuperà di verificare il lavoro una volta terminato e di monitorare l'evolversi dell'issue.

\section{Gestione Issues}
Per i cambiamenti di stato delle issue fate riferimento alla guida presente su Google Sites, \href{https://sites.google.com/site/xideproject/guide-e-tutorial/google-code-issue}{Google Code: Issue}. Ogni membro è tenuto inoltre ad aggiungere nei commenti ove possibile il codice della revisione a cui il commento fa riferimento. Ossia se con la revisione (r49) considero un \textit{task} come \textit{Done} allora nel commento in cui segnalo come concluso l'issue aggiungo anche il codice della revisione (che Google Code trasformerà in un link alla revisione stessa). Inoltre se con la revisione (r49) ho incrementato la versione del documento modificato, devo segnalarlo nel commento dell'issue.

\section{Notifiche Issue}
Nel campo CC va generalmente inserito il nome del verificatore. Solo in casi particolari si rende necessario inserire più di un nome. Nel caso non si sia sicuri di quali persone sia necessario inserire è obbligatorio creare un \textit{alert} con l'indirizzo dell'issue in modo che i diretti interessati provvedano da se a inserire il proprio nome. In ogni caso se qualcuno viene inserito come CC in issue, ma per motivi di studio o lavoro non può interessarsi a quell'issue o non vuole ricevere le continue notifiche di aggiornamento è bene che si cancelli dal campo CC.

\section{Modifiche al sommario delle Issue}
Nel caso il contenuto (\textit{task} o \textit{defect}) di un'issue cambi nel tempo, il verificatore di tale issue è tenuto a modificare il sommario (titolo/riassunto) della stessa in modo che rispecchi le attuali richieste presentate in essa. Se per esempio un \textit{task} viene creato come ``Convertire PNG in EPS'' e più avanti ci si accorge che bisogna in realtà convertire da SVG a EPS, allora anche il titolo/sommario dell'issue và aggiornato in modo da rispecchiare il contenuto attuale dell'issue. Questo serve a garantire una migliore ricerca dell'issue in quanto i titoli vecchi vengono comunque salvati e quelli nuovi ottengono precedenza nelle ricerche basate sul titolo.

\section{Verifica}
La verifica avviene durante il processo e al termine dello stesso. Durante il processo infatti il verificatore deve occupparsi di correggere lo stato, la priorità e altri fattori di un issue, nonchè di verificare che tutte le norme comportamentali vengano rispettate. Al termine del lavoro, ossia quando l'issue viene marcato come \textit{Done} o \textit{Fixed} il verificatore deve controllare che tutte le premesse e i compiti assegnati siano stati eseguiti, o nel caso di un difetto che tale difetto sia stato eliminato. Inoltre il verificatore deve partendo dalle sezioni interessate di questo documento verificare che tutte le norme interessate siano state rispettate.\\
Il verificatore può correggere in modo autonomo gli errori solo se essi sono minimali (lettere errate, punteggiature) o se è estremamente sicuro della correzione che sta applicando. Ogni qual volta infatti la parte errata abbia una certa consistenza e/o vi siano diversi modi di risolverla, il verificatore deve segnalarlo nell’issue senza prendere iniziative.

\section{Software obbligatorio}
Ogni componente del gruppo è tenuto ad avere installati (o supportare) sul proprio sistema i seguenti software.
\begin{itemize}
\item \textbf{SH}: (\href{http://en.wikipedia.org/wiki/Bourne_shell}{Bourne Shell - Wikipedia}) è necessario per l'utilizzo dello script \textit{pdf.sh} con il quale viene lanciata la compilazione dei documenti Latex.
\item \textbf{Inkscape} (\textit{0.46} o superiore): (\href{http://en.wikipedia.org/wiki/Inkscape}{Inkscape - Wikipedia}) è necessario per la conversione dei diagrammi nei documenti dal formato \href{http://en.wikipedia.org/wiki/Svg}{SVG} al formato \href{http://en.wikipedia.org/wiki/Encapsulated_PostScript}{EPS}.
\end{itemize}
La presenza e l'utilizzo di tali software sono necessari ad un corretto e veloce sviluppo del software, minimizzando gli errori e massimizzando la qualità.